Support CRYSTAL_LIBRARY_RPATH for adding dynamic library lookup paths
#13499
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
straight-shoota
approved these changes
May 26, 2023
| @@ -334,7 +334,7 @@ class Crystal::Command | |||
| output_format : String?, | |||
| combine_rpath : Bool do | |||
| def compile(output_filename = self.output_filename) | |||
| compiler.emit_base_filename = original_output_filename | |||
| compiler.emit_base_filename = output_filename.rchop(File.extname(output_filename)) | |||
There was a problem hiding this comment.
This is equivalent and more concise:
Suggested change
| compiler.emit_base_filename = output_filename.rchop(File.extname(output_filename)) | |
| compiler.emit_base_filename = Path[output_filename].stem |
There was a problem hiding this comment.
This is from a prior PR. That PR actually changed the behavior of -o so that it also affects --emit; previously those emitted files would always be in the current working directory and ignore the name given to -o. Thus output_filename could now contain directory separators, and calling Path#stem would remove them.
There was a problem hiding this comment.
I guess the name filename is misleading then if it's actually a path.
But okay, don't need to fix that here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #13490, except for the interpreter part.
The
CRYSTAL_LIBRARY_RPATHenvironment variable can be used to pass a list of directories used by built programs to locate their dynamic libraries at run time.$ORIGINand${ORIGIN}are expanded into the program's absolute path, and this PR adds a custom implementation for this on Windows, only available if the delay-load helper is present (i.e.-Dno_win32_delay_loadis not used). Linux's loader also expands$LIBand$PLATFORM, although this is not guaranteed.The compiler will automatically add its own RPATH to anything that needs to be compiled and run immediately as a child process. For Windows, this means as long as the compiler can find its own DLLs,
crystal run -Dpreview_dll/eval/specor any macroruninsidecrystal build -Dpreview_dllwill always be able to locate the same DLLs distributed along the compiler itself, even if the compiler is not in%PATH%. In principle, if the compiler itself is dynamically linked with aCRYSTAL_LIBRARY_RPATHcontaining$ORIGIN, then the DLLs do not even have to share the same directory as the compiler.For most Unix-like systems, this automatically passes
-Wl,-rpath,...to the linker. It seems linkers disagree on whether that option affects RPATH or RUNPATH. macOS is excluded because it handles library lookup differently.The compiler automatically generates the
Crystal::LIBRARY_RPATHconstant; when a Crystal source is run, this constant will reflect the contents of both the environment variable and the compiler itself, as described above. The standard library also defines it explicitly in case a compiler without this PR tries to use it.